Note

Medium Risk
Changes error shapes thrown from core signing and transaction-failure paths; consumers that matched on raw hardware error text or KeyringControllerError wrapping may see different errors, though behavior for genuine user rejections is more correct.

Overview
Hardware wallets (e.g. Trezor) often surface user cancellations as vague strings or wrapped errors instead of EIP-1193 userRejectedRequest (4001). This PR aligns signing and transaction failure paths so UIs and downstream code can treat rejections consistently.

KeyringController adds @metamask/rpc-errors and wraps signMessage, signPersonalMessage, signTransaction, and (when applicable) signTypedMessage so cancellation-like failures become providerErrors.userRejectedRequest with the standard MetaMask denial message, preserving optional data when present. Detection recurses through code, message, stack, cause, and originalError, including 4001, cancel/canceled strings, and failure_actioncancelled.

TransactionController adds parallel #hasUserRejectedMessage logic (including a Trezor “unknown error” string heuristic) and, in #failTransaction, persists and publishes the normalized rejection error on failed txs and transactionFailed events instead of opaque hardware errors.

Changelogs and broad test coverage document the new behavior; transaction signing tests mock KeyringController:signTransaction to exercise the path.

^{Reviewed by Cursor Bugbot for commit fc5e685. Bugbot is set up for automated code reviews on this repo. Configure here.}